Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

204
Views
Red Hat Linux: "desactivar" la comprobación de cifrado

Tengo una implementación de Red Hat 6.5 Linux que usa LUKS para cifrar el sistema y, por razones que no son relevantes, me gustaría "desactivar" la comprobación de cifrado de arranque durante un período de tiempo. Se volverá a activar en algún momento, por lo que incluso si es posible eliminar el cifrado LUKS por completo, esa no es una solución que me interese.

Lo que quiero es proporcionar automáticamente la contraseña de LUKS en el arranque para que no sea necesario ingresarla manualmente; por lo tanto, lógicamente "apagar" el cifrado aunque todavía esté habilitado.

Ahora, si bien esto es sencillo para dispositivos secundarios, es decir. al crear un archivo de clave, aplicar el archivo de clave a los dispositivos encriptados y modificar /etc/crypttab para hacer referencia al archivo de clave, aún debe ingresar al menos una contraseña en el arranque, porque, si el dispositivo principal está encriptado con LUKS, entonces primero tiene que ser descifrado antes de que /etc/crypttab sea accesible.

Hay una forma que he visto de eliminar el requisito de ingresar la contraseña inicial, que es:

  1. crear un archivo clave
  2. aplicar el archivo clave al dispositivo cifrado, es decir. habilitar la clave para que el dispositivo sea descifrado
  3. Copie el archivo de clave en un dispositivo extraíble no cifrado (por ejemplo, una unidad flash)
  4. agregue rd.luks.key= ruta absoluta al archivo de clave : dispositivo extraíble no encriptado a la línea del kernel de arranque en /boot/grub/grub.conf
  5. En el arranque, asegúrese de que el dispositivo extraíble no cifrado esté insertado y pueda ser referenciado por el proceso de arranque.

Todo esto se ve bien, excepto que no quiero un dispositivo extraíble no encriptado involucrado. Simplemente quiero que el servidor arranque como si no estuviera encriptado.

La única forma que veo para lograr esto es reemplazar el dispositivo no cifrado extraíble con un dispositivo no cifrado normal . En cuyo caso, el proceso de arranque leería el dispositivo normal no cifrado , obtendría la clave y la usaría para descifrar los dispositivos cifrados... ¡hey, el cifrado está deshabilitado!

El único dispositivo que puedo encontrar en mi sistema que cumple con los criterios normales de dispositivos no cifrados es /dev/sda1, es decir. /boot, así que realicé los pasos anteriores con los pasos 3 y 4 de la siguiente manera:

  1. como anteriormente
  2. como anteriormente
  3. copie el archivo clave a /boot/keyfile.key
  4. agregar rd.luks.key=/boot/keyfile.key:/dev/sda1
  5. n / A

Desafortunadamente, parece que no puedo hacer que esto funcione.

Red Hat arranca y no se me pide una contraseña (como se esperaba), sin embargo, hacia el final del proceso de arranque, falla con "Pánico en el kernel: no se sincroniza: se intentó matar a init! ..."

Este comportamiento es idéntico cualquiera de los siguientes que use:

  • rd.luks.key=/boot/keyfile.key:/dev/sda1
  • rd.luks.key=/keyfile.key:/dev/sda1
  • rd.luks.key=/archivoclave.clave
  • rd.luks.key=/ algúnArchivoClaveQueConozcoNoExiste.key :/dev/sda1

Entonces mis preguntas son las siguientes:

  1. ¿Es posible lo que estoy tratando de hacer?
  2. Si es así, entonces...
    • ¿Dónde debo poner el archivo clave?
    • ¿Cuál es el valor rd.luks.key que debo usar para hacer referencia al archivo clave?

Gracias de antemano por cualquier ayuda

over 4 years ago · Santiago Trujillo
2 answers
Answer question

0

Después de mucho investigar, finalmente encontré la respuesta (que funciona tanto en CentOS 6.6 como en 7). Gracias a los siguientes 2 recursos en particular:

  • Deshabilitar el cifrado LUKS
  • RedHat Bug 751640 - dracut ignora el archivo de claves crypttab

Lo que hice fue lo siguiente (como usuario root):

 # insert a password into my chosen password file echo -n "anypassword" > /etc/mypasswdfile # instruct the LUKS device to take the password from my password file vi /etc/crypttab and replaced the 3rd parameter "none" with "/etc/mypasswdfile" # add my password file as a valid key for the luks device cryptsetup luksAddKey /dev/sda2 /etc/mypasswdfile # configure dracut to add the following 2 items to the initramfs (so accessible at boot) echo 'install_items="/etc/mypasswdfile /etc/crypttab"' > /etc/dracut.conf.d/99-mypwfile.conf # instruct dracut to apply the configuration dracut -f # reboot the server reboot

Y eso es. El servidor se reinicia sin solicitar una contraseña. (Esto se puede deshabilitar/habilitar a voluntad eliminando/agregando el archivo de claves del dispositivo LUKS a través del comando cryptsetup)

over 4 years ago · Santiago Trujillo Report

0

Nunca tuve la necesidad de esto, pero ciertamente puedo relacionarme con su utilidad. Entonces, su publicación me impulsó a revisar cómo se podría hacer esto, y la única forma que veo es obtener los scripts/detalles de desbloqueo en initramfs.

Este es un proceso mucho más fácil en distribuciones basadas en Debian, porque es posible inyectar scripts en initramfs a través de initramfs-tools... dinámicamente en el arranque. Ver esto y esto y esto

Las distribuciones basadas en RHEL requerirían el uso de dracut (en modo de recuperación) para reconstruir initramfs. Por lo tanto, creo que puede resolver este problema reconstruyendo initramfs e inyectando sus scripts de desbloqueo allí ... de esa manera podemos estar seguros de que su dispositivo raíz/arranque se haya desbloqueado antes de que el kernel necesite montarlos. Este hilo de Gentoo sugiere una forma de acceder y modificar los contenidos de initramfs. En cuanto a la mejor manera de inyectar sus scripts de desbloqueo en initramfs, no estoy seguro de eso.

Sin duda intentaré esto cuando esté menos ocupado. Suena algo bastante útil para poder configurar.

over 4 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!